1. Field of Disclosure
This disclosure relates to functional verification of system of chip designs generally, and specifically to improved functional verification of system on chip designs using constrained random verification from both debug and development perspectives.
2. Description of the Related Art
Constrained random verification has been widely adopted for functional verification of complex chip designs. In a typical constrained random simulation methodology, a TestBench will generate random stimulus as inputs to drive the simulation. The random stimuli cannot be arbitrarily random values; rather, they must encapsulate the environment surrounding the design-under-test (DUT). Hence, the user typically writes a set of constraints (e.g., using System Verilog) to restrict the random stimulus. During simulation, a constraint solver (e.g., in a Verilog Compiled Simulator) will find a random solution that satisfies the user specified constraints, and the TestBench will use the constraint solver result to drive the simulation. In order for the simulation to make forward progress, the constraint solver is called repeatedly to generate random stimuli. As the design projects and verification tasks grow exponentially, the complexity of their constraints also explodes drastically.
In cases where the constraints are not written or organized properly, users can run into different problems. For example, randomization may fail due to inconsistencies in the constraints, errors (e.g., out of bound indexing), timeouts may occur (e.g., while processing difficult constraints), etc. These are problems indicated by the constraint solver in the simulator which could cause the simulation to terminate prematurely. The simulator may provide a clear point of failure for the TestBench developer to debug. There are other types of problems that require more effort to identify the true point of failure. For example, while a randomization is successful (i.e., a solution is found to satisfy the constraints) the generated test stimulus values may not correspond with expected values due to an incorrect or incomplete specification of constraints. The unexpected values propagate to the rest of the system and eventually cause other error symptoms to show up deeper in the design. To back track the error symptom to the problematic randomization may take additional debug effort. Another problem may be related to the solution distribution of the constrained random values. Not all solutions of the randomization share the same level of functional significance to the design verification problem. If some of the functional significant solution values are generated with less probability, it could mean additional randomizations of stimuli using a larger number of tests and/or making some tests run longer.
Debug activities for constraints are typically carried out on the text information printed by the simulator. Users would have to analyze the information manually, modify the code, re-compile, and rerun simulation to verify a tentative solution to the problem. There are a number of inefficiencies in this methodology. Processing the text information, which may be lengthy for a complex randomization problem, can be time consuming. Also, compilation time for a large system on chip (SoC) design can be long, and having to repeatedly debug, recompile, and re-execute the simulation can be a time consuming process. Additionally, this manual process would occur in an iterative process, until the user correct the problem in the constraints—which may be very time intensive. Moreover, with the increased use of standardized verification methodologies as well as verification intellectual property (IP) coming from different design teams and commercial vendors, the users debugging constraints do not necessarily know where the randomize calls are in the TestBench code and/or what constraints may have already existed within the verification IP that the user is building and debugging on top of.
Most of the debug activities are reactive to address some failure symptoms in functional verification of the design. This implies that unless there are specific observers or checkers for these symptoms in the verification environment, many of the solution space and distribution space related constraint problem on the stimulus are undetected, risking real design failures in the real systems. Due to these dependencies, many of the solution and distribution space related constraint problems are generally detected later in the TestBench development cycle.